-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix (visually) removing first notification when executing an action #1657
Fix (visually) removing first notification when executing an action #1657
Conversation
When an action is executed first its element is faded out and then the notification data is removed, which removes the component as a whole. However, the index of the notification was not provided, so the event that handles the "remove" event always removed the data of the first notification. Due to this when the action was triggered in another notification the first notification was also (visually) removed (and only until the notifications were fetched again from the server). Signed-off-by: Daniel Calviño Sánchez <[email protected]>
So the fact that I was seeing this only with 2 tabs and the message
was just a coincidence? |
I was intrigued by that as well 🤷 Maybe there is something else, but at least I was able to reproduce the issue with a single tab and the steps above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was unable to reproduce it the way you described in only one tab, but still this PR seems to fix the issue I was seeing.
Also it makes sense, because on dismissal the index is already there:
notifications/src/Components/Notification.vue
Line 329 in 9e4bfdc
this.$emit('remove', this.index) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and works 👍
I guess we backport till 25? |
That was what I was counting on the backportbot to do. Of course it would have helped if I have called it... 🤦 |
/backport to stable27 |
/backport to stable26 |
/backport to stable25 |
The backport to stable27 failed. Please do this backport manually. # Switch to the target branch and update it
git checkout stable27
git pull origin stable27
# Create the new backport branch
git checkout -b fix/foo-stable27
# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts. Resolve them.
git cherry-pick abc123
# Push the cherry pick commit to the remote repository and open a pull request
git push origin fix/foo-stable27 More info at https://docs.nextcloud.com/server/latest/developer_manual/getting_started/development_process.html#manual-backport |
The backport to stable26 failed. Please do this backport manually. # Switch to the target branch and update it
git checkout stable26
git pull origin stable26
# Create the new backport branch
git checkout -b fix/foo-stable26
# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts. Resolve them.
git cherry-pick abc123
# Push the cherry pick commit to the remote repository and open a pull request
git push origin fix/foo-stable26 More info at https://docs.nextcloud.com/server/latest/developer_manual/getting_started/development_process.html#manual-backport |
The backport to stable25 failed. Please do this backport manually. # Switch to the target branch and update it
git checkout stable25
git pull origin stable25
# Create the new backport branch
git checkout -b fix/foo-stable25
# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts. Resolve them.
git cherry-pick abc123
# Push the cherry pick commit to the remote repository and open a pull request
git push origin fix/foo-stable25 More info at https://docs.nextcloud.com/server/latest/developer_manual/getting_started/development_process.html#manual-backport |
Oh, the irony... I will manually do the backports then. |
Well compiled assets, so it's expected |
When an action is executed first its element is faded out and then the notification data is removed, which removes the component as a whole. However, the index of the notification was not provided, so the event that handles the "remove" event always removed the data of the first notification. Due to this when the action was triggered in another notification the first notification was also (visually) removed (and only until the notifications were fetched again from the server).
How to test
Result with this pull request
The last notification is removed
Result without this pull request
Both the first and the last notifications are removed. If you keep the notifications open long enough (so the notifications are fetched again) the first notification will appear again